יצירת טקסט משוחזר גנרי: התוכנית המפורטת לשיפור נתוני AI בטוחים מסוג

בנוף המתפתח במהירות של בינה מלאכותית, מודלים גדולים של שפה (LLM) הופיעו ככלים טרנספורמטיביים, המסוגלים ליצור טקסט הדומה להפליא לטקסט אנושי, לסכם מסמכים מורכבים ואף לכתוב קוד. עם זאת, למרות כל הכוח היצירתי שלהם, ארגונים ברחבי העולם מתמודדים עם אתגר קריטי: רתימת הכוח הזה למשימות קריטיות למשימה הדורשות דיוק, אמינות ומבנה. האופי היצירתי, לעתים בלתי צפוי של מודלי LLM יכול להיות חיסרון כאשר המטרה היא לעבד נתונים, לא רק ליצור פרוזה.

כאן נכנסת לתמונה הפרדיגמה של יצירת טקסט משוחזר (RAG), המעגנת מודלי LLM בנתונים עובדתיים וספציפיים לתחום. אבל גם ל-RAG יש מגבלה נסתרת. הוא מייצר לעתים קרובות טקסט לא מובנה הדורש עיבוד שלאחר מכן שביר ונוטה לשגיאות. הפתרון? גישה מתקדמת ויציבה יותר: יצירת טקסט משוחזר גנרי עם בטיחות סוג. מתודולוגיה זו מייצגת קפיצת מדרגה עצומה קדימה, והופכת מודלי LLM משיחהנים חכמים למנועי עיבוד נתונים ממושמעים ואמינים שיכולים להניע את הדור הבא של אוטומציה ארגונית.

מדריך מקיף זה יבחן את הטכניקה החדשנית הזו, יפרק את מרכיביה, יציג את היישומים הגלובליים שלה ויספק תוכנית מפורטת ליישום. נצא למסע מיסודות LLM ו-RAG לעולם המתוחכם של חילוץ נתונים מובנים ובטוחים מסוג, ונחשוף כיצד לבנות מערכות AI שתוכלו לסמוך עליהן באמת.

הבנת היסודות: ממודלי LLM ל-RAG

כדי להעריך את המשמעות של RAG בטוח מסוג, עלינו להבין תחילה את אבני הבניין שעליהן הוא עומד. האבולוציה ממודלי LLM עצמאיים למערכות RAG מודעות הקשר מכינה את הבמה לחדשנות ברמה הבאה הזו.

העוצמה והסכנה של מודלים גדולים של שפה (LLM)

מודלים גדולים של שפה הם מודלים של למידה עמוקה שאומנו על כמויות עצומות של נתוני טקסט מרחבי האינטרנט. הכשרה זו מאפשרת להם להבין וליצור שפה ברמת שטף מדהימה. הכוח העיקרי שלהם טמון ביכולתם לזהות דפוסים, הקשר וניואנסים בתקשורת אנושית.

• חוזקות: מודלי LLM מצטיינים במשימות כמו יצירת תוכן, תרגום, סיכום וסיעור מוחות. הם יכולים לנסח מיילים, לכתוב טקסט שיווקי ולהסביר נושאים מורכבים במונחים פשוטים.
• חולשות: הידע שלהם קפוא בזמן ההכשרה האחרונה שלהם, מה שהופך אותם ללא מודעים לאירועים אחרונים. באופן קריטי יותר, הם נוטים ל"הזיות" - להמציא בעצמה עובדות, נתונים או מקורות. עבור כל תהליך עסקי המסתמך על דיוק עובדתי, זהו סיכון בלתי מתקבל על הדעת. יתר על כן, הפלט שלהם, כברירת מחדל, הוא פרוזה לא מובנית.

כניסה ליצירת טקסט משוחזר (RAG): עיגון AI במציאות

RAG פותח כדי להפחית את החולשות העיקריות של מודלי LLM. חשבו על זה כעל מתן למודל בחינה עם ספר פתוח במקום לבקש ממנו להיזכר בכל דבר מהזיכרון. התהליך פשוט באלגנטיות אך עוצמתי:

1. אחזור: כאשר משתמש שואל שאלה, מערכת ה-RAG אינה שולחת אותה מיד למודל LLM. במקום זאת, היא מחפשת תחילה בבסיס ידע פרטי ואצור (כגון מסמכים פנימיים של החברה, מדריכי מוצרים או מסד נתונים של דוחות כספיים) מידע רלוונטי. בסיס ידע זה מאוחסן לעתים קרובות במסד נתונים וקטורי מיוחד לחיפוש סמנטי יעיל.
2. הרחבה: פיסות המידע הרלוונטיות שאוחזרו מבסיס הידע משולבות לאחר מכן עם השאלה המקורית של המשתמש. טקסט משולב זה, עשיר בהקשר עובדתי, יוצר הנחיה חדשה ומשופרת.
3. יצירה: הנחיה מורחבת זו נשלחת לאחר מכן למודל LLM. כעת, למודל יש את המידע הספציפי, העדכני והעובדתי שהוא צריך כדי ליצור תשובה מדויקת ורלוונטית, תוך ציטוט ישיר של מקורותיו.

RAG הוא מחליף משחק. הוא מפחית באופן דרמטי הזיות, מאפשר למודלי LLM להשתמש בנתונים קנייניים ובזמן אמת ומספק מנגנון לאימות מקור. זו הסיבה שכל כך הרבה כלי צ'אטבוט AI וכלי חיפוש ארגוניים מודרניים הם יעילים. אבל זה עדיין לא פותר בעיה מכרעת אחת.

האתגר הנסתר: בעיית ה"סוג" ב-RAG רגיל

בעוד ש-RAG מבטיח שה*תוכן* של תגובת LLM מעוגן עובדתית, הוא לא מבטיח את ה*מבנה* שלה. הפלט הוא בדרך כלל בלוק של טקסט בשפה טבעית. עבור יישומים ארגוניים רבים, זהו מפריע עסקה.

מתי "מספיק טוב" זה לא מספיק טוב

תארו לעצמכם שאתם צריכים להפוך לאוטומטי את העיבוד של חשבוניות נכנסות מספקים ברחבי העולם. המטרה שלכם היא לחלץ מידע מפתח ולהזין אותו למערכת הנהלת החשבונות שלכם. מערכת RAG רגילה עשויה לספק סיכום מועיל:

"החשבונית היא מ-'Global Tech Solutions Inc.', מספר INV-2023-945. הסכום הכולל לתשלום הוא 15,250.50 EUR, והתשלום אמור להתבצע עד 30 באוקטובר 2023. הפריטים המפורטים כוללים 50 יחידות של 'שרתים בעלי ביצועים גבוהים' ו-10 'מתגי רשת ארגוניים'."

זה מדויק, אבל זה לא שמיש מבחינה תוכנתית. כדי להכניס נתונים אלה למסד נתונים, מפתח יצטרך לכתוב קוד ניתוח מורכב באמצעות ביטויים רגולריים או טכניקות אחרות של מניפולציה של מחרוזות. קוד זה שביר לשמצה. מה אם התגובה הבאה של LLM תאמר "מועד התשלום הוא..." במקום "אמור להתבצע עד...?" מה אם סמל המטבע מופיע לפני המספר? מה אם התאריך הוא בפורמט אחר? המנתח נשבר, והאוטומציה נכשלת.

העלות הגבוהה של פלטים לא מובנים

• מורכבות פיתוח מוגברת: צוותי הנדסה משקיעים זמן יקר בכתיבה ותחזוקה של לוגיקת ניתוח שבירה במקום לבנות תכונות עסקיות עיקריות.
• שבריריות מערכת: וריאציות קטנות ובלתי צפויות בפורמט הפלט של LLM עלולות לגרום לכל צינור עיבוד הנתונים להיכשל, מה שמוביל להשבתה יקרה ולבעיות שלמות נתונים.
• אובדן הזדמנויות אוטומציה: מקרי שימוש אוטומטיים בעלי ערך רבים נחשבים מסוכנים או מורכבים מדי ליישום בגלל חוסר האמינות של ניתוח טקסט לא מובנה.
• בעיות מדרגיות: מנתח שנכתב עבור סוג מסמך או שפה אחת עשוי שלא לעבוד עבור אחר, מה שמפריע למדרגיות גלובלית.

אנחנו צריכים דרך לאכוף חוזה עם ה-AI, ולהבטיח שהפלט שלו לא רק נכון עובדתית אלא גם מובנה בצורה מושלמת, בכל פעם.

RAG גנרי עם בטיחות סוג: שינוי הפרדיגמה

כאן נכנס לתמונה המושג של בטיחות סוג, שאול משפות תכנות מודרניות, שמחולל מהפכה במסגרת ה-RAG. זהו מעבר יסודי מתקווה לפורמט הנכון להבטחת הפורמט.

מהי "בטיחות סוג" בהקשר של AI?

בשפות תכנות כמו TypeScript, Java או Rust, בטיחות סוג מבטיחה שמשתנים ופונקציות מצייתים למבנה מוגדר מראש או "סוג". אי אפשר לשים בטעות מחרוזת טקסט במשתנה שאמור להכיל מספר. זה מונע סוג שלם של באגים והופך את התוכנה ליציבה וצפויה יותר.

כאשר מוחלים על AI, בטיחות סוג פירושה הגדרת סכימת נתונים קפדנית עבור הפלט של LLM ושימוש בטכניקות כדי לאלץ את תהליך היצירה של המודל לציית לסכימה זו. זה ההבדל בין לבקש מה-AI "ספר לי על החשבונית הזו" ולפקוד עליו "מלא את טופס נתוני החשבונית הזה, ואסור לך לחרוג מהמבנה שלו."

הרכיב ה"גנרי": בניית מסגרת אוניברסלית

ההיבט ה"גנרי" חשוב לא פחות. מערכת בטוחה מסוג המקודדת קשה רק עבור חשבוניות מועילה, אך מערכת גנרית יכולה להתמודד עם כל משימה שתטילו עליה. זוהי מסגרת אוניברסלית שבה התשומות יכולות להשתנות:

• כל מקור נתונים: קבצי PDF, הודעות דוא"ל, תגובות API, רשומות מסד נתונים, תמלילי תמיכת לקוחות.
• כל סכימת יעד: המשתמש מגדיר את מבנה הפלט הרצוי תוך כדי תנועה. היום זו סכימת חשבונית; מחר זו סכימת פרופיל לקוח; למחרת זו סכימת נתוני ניסוי קליני.

זה יוצר כלי רב עוצמה וניתן לשימוש חוזר להמרת נתונים חכמה, המופעל על ידי LLM אך עם האמינות של תוכנה מסורתית.

כיצד זה עובד: פירוט שלב אחר שלב

מערכת RAG גנרית ובטוחה מסוג משפרת את צינור ה-RAG הסטנדרטי עם שלבים חדשים מכריעים:

1. הגדרת סכימה: התהליך מתחיל בכך שהמשתמש מגדיר את מבנה הפלט הרצוי. זה נעשה לעתים קרובות באמצעות פורמט סטנדרטי וקריא על ידי מכונה כמו JSON Schema, או באמצעות קוד באמצעות ספריות כמו Pydantic בפייתון. סכימה זו משמשת כחוזה בלתי שביר עבור ה-AI.
2. אחזור הקשר: שלב זה נשאר זהה כמו ב-RAG רגיל. המערכת מאחזרת את המסמכים או חלקי הנתונים הרלוונטיים ביותר מבסיס הידע כדי לספק הקשר.
3. הנדסת הנחיות מוגבלת: כאן הקסם קורה. ההנחיה מעוצבת בקפידה כדי לכלול לא רק את השאלה של המשתמש ואת ההקשר שאוחזר, אלא גם ייצוג ברור וחד משמעי של סכימת היעד. ההוראות מפורשות: "בהתבסס על ההקשר הבא, חלץ את המידע הנדרש ועצב את התגובה שלך כאובייקט JSON המאמת מול סכימה זו: [הגדרת הסכימה מוכנסת כאן]."
4. יצירת מודל עם אילוצים: זהו החלק המתקדם ביותר. במקום רק לתת למודל LLM ליצור טקסט בחופשיות, כלים וטכניקות מיוחדים מנחים את הפלט שלו אסימון אחר אסימון. לדוגמה, אם הסכימה דורשת ערך בוליאני (`true` או `false`), תהליך היצירה מוגבל לייצר רק את האסימונים הספציפיים האלה. אם הוא מצפה למספר, לא יורשה לו ליצור אותיות. זה מונע באופן יזום מהמודל לייצר פורמט לא חוקי.
5. אימות וניתוח: הפלט שנוצר (לדוגמה, מחרוזת JSON) מאומת לאחר מכן מול הסכימה המקורית. הודות ליצירה המוגבלת, כמעט מובטח ששלב זה יעבור. התוצאה היא אובייקט נתונים מובנה בצורה מושלמת ובטוחה מסוג, מוכן לשימוש מיידי בכל יישום או מסד נתונים מבלי צורך בלוגיקת ניתוח שבירה ומותאמת אישית.

יישומים מעשיים בתעשיות גלובליות

את העוצמה של גישה זו מבינים בצורה הטובה ביותר באמצעות דוגמאות מהעולם האמיתי המשתרעות על פני מגזרים מגוונים ובינלאומיים. היכולת להתמודד עם פורמטים ושפות מסמכים מגוונים תוך פלט של מבנה סטנדרטי היא מאפשרת עסקים גלובלית.

פיננסים ובנקאות (ציות גלובלי)

• משימה: בנק השקעות גלובלי צריך לעבד אלפי חוזים פיננסיים מורכבים, כמו הסכמי ISDA או מסמכי הלוואה מאוגדים, הנשלטים על ידי חוקי תחומי שיפוט שונים (לדוגמה, ניו יורק, לונדון, סינגפור). המטרה היא לחלץ התחייבויות מפתח, תאריכים ופרטי צד נגדי לניהול סיכונים.
• הגדרת סכימה:

              {
      "contract_id": "string",
      "counterparty_name": "string",
      "governing_law": "string",
      "principal_amount": "number",
      "currency": "enum[\"USD\", \"EUR\", \"GBP\", \"JPY\", \"CHF\"]",
      "key_dates": [
          { "date_type": "string", "date": "YYYY-MM-DD" }
      ]
  }
              
  
                
                  Copy
                
              
            

• יתרון: המערכת יכולה לקלוט חוזה PDF מכל אזור, לאחזר סעיפים משפטיים ופיננסיים רלוונטיים ולהפיק אובייקט JSON סטנדרטי. זה מצמצם באופן דרסטי את שבועות העבודה הידנית שנעשית על ידי צוותים משפטיים וציות, מבטיח עקביות נתונים עבור מודלים גלובליים של סיכונים וממזער את הסיכוי לטעות אנוש.

בריאות ומדעי החיים (מחקר בינלאומי)

• משימה: חברת תרופות רב לאומית מנהלת ניסוי קליני במרכזים בצפון אמריקה, אירופה ואסיה. הם צריכים לחלץ ולתקנן דוחות על תופעות לוואי של מטופלים, שלעתים קרובות מוגשים כטקסט נרטיבי לא מובנה על ידי רופאים בשפות שונות.
• הגדרת סכימה:

              {
      "patient_id": "string",
      "report_country": "string",
      "event_description_raw": "string",
      "event_severity": "enum[\"mild\", \"moderate\", \"severe\"]",
      "suspected_medications": [
          { "medication_name": "string", "dosage": "string" }
      ],
      "meddra_code": "string" // Medical Dictionary for Regulatory Activities code
  }
              
  
                
                  Copy
                
              
            

• יתרון: ניתן לעבד דוח שנכתב בגרמנית כדי להפיק את אותו פלט אנגלי מובנה כמו דוח שנכתב ביפנית. זה מאפשר צבירה וניתוח מהירים של נתוני בטיחות, ועוזר לחוקרים לזהות מגמות מהר יותר ומבטיח ציות לגופים רגולטוריים בינלאומיים כמו ה-FDA וה-EMA.

לוגיסטיקה ושרשרת אספקה (פעולות ברחבי העולם)

• משימה: ספק לוגיסטיקה גלובלי מעבד מדי יום עשרות אלפי מסמכי משלוח - שטר מטען, חשבוניות מסחריות, רשימות אריזה - מספקים וממדינות שונות, שלכל אחת מהן פורמט ייחודי משלה.
• הגדרת סכימה:

              {
      "tracking_number": "string",
      "carrier": "string",
      "origin": { "city": "string", "country_code": "string" },
      "destination": { "city": "string", "country_code": "string" },
      "incoterms": "string",
      "line_items": [
          { "hscode": "string", "description": "string", "quantity": "integer", "unit_weight_kg": "number" }
      ]
  }
              
  
                
                  Copy
                
              
            

• יתרון: אוטומציה של הצהרות מכס, עדכונים בזמן אמת למערכות מעקב ונתונים מדויקים לחישוב עלויות משלוח ותעריפים. זה מבטל עיכובים יקרים הנגרמים על ידי שגיאות בהזנת נתונים ידנית ומייעל את זרימת הסחורות מעבר לגבולות בינלאומיים.

יישום RAG גנרי עם בטיחות סוג: כלים ושיטות עבודה מומלצות

בניית מערכת כזו נגישה יותר מאי פעם, הודות למערכת אקולוגית גדלה של כלים בקוד פתוח ושיטות עבודה מומלצות מבוססות.

טכנולוגיות ומסגרות מפתח

בעוד שאתם יכולים לבנות מערכת מאפס, מינוף ספריות קיימות יכול להאיץ את הפיתוח באופן משמעותי. הנה כמה שחקני מפתח במערכת האקולוגית:

• מסגרות תזמורת: LangChain ו-LlamaIndex הן שתי המסגרות הדומיננטיות לבניית צינורות RAG. הם מספקים מודולים לטעינת נתונים, אינדקס, אחזור וחיבור שיחות LLM יחד.
• הגדרת סכימה ואימות: Pydantic היא ספריית פייתון שהפכה לסטנדרט דה פקטו להגדרת סכימות נתונים בקוד. ניתן להמיר את המודלים שלה בקלות ל-JSON Schema. JSON Schema עצמה היא תקן אגנוסטי לשפה, מושלם עבור מערכות הבנויות על פני ערימות טכנולוגיות שונות.
• ספריות יצירה מוגבלות: זהו מרחב חדשני במהירות. ספריות כמו Instructor (עבור מודלי OpenAI), Outlines ו-Marvin תוכננו במיוחד כדי לאלץ את פלטי LLM לציית ל-Pydantic או JSON Schema נתונים, ובכך להבטיח למעשה בטיחות סוג.
• מסדי נתונים וקטוריים: עבור החלק ה"אחזור" של RAG, מסד נתונים וקטורי חיוני לאחסון ולחיפוש יעיל של כמויות גדולות של נתוני טקסט. אפשרויות פופולריות כוללות את Pinecone, Weaviate, Chroma ו-Qdrant.

שיטות עבודה מומלצות ליישום חזק

1. התחילו עם סכימה מוגדרת היטב: הבהירות והאיכות של סכימת היעד שלכם הן בעלות חשיבות עליונה. היא צריכה להיות ספציפית ככל האפשר. השתמשו ב-enums עבור בחירות קבועות, הגדירו סוגי נתונים (מחרוזת, מספר שלם, בוליאני) ותארו כל שדה בבירור. סכימה מעוצבת היטב היא הבסיס למערכת אמינה.
2. שפרו את אסטרטגיית האחזור שלכם: העיקרון של "זבל נכנס, זבל יוצא" חל. אם אתם מאחזרים הקשר לא רלוונטי, ה-LLM יתקשה למלא את הסכימה כראוי. נסו אסטרטגיות שונות של חלוקת מסמכים, הטבעת מודלים וטכניקות אחזור (לדוגמה, חיפוש היברידי) כדי להבטיח שההקשר המסופק ל-LLM צפוף במידע רלוונטי.
3. הנדסת הנחיות איטרטיבית ומפורשת: ההנחיה שלכם היא מדריך ההוראות עבור ה-LLM. היו מפורשים. ציינו בבירור את המשימה, ספקו את ההקשר והטביעו את הסכימה עם פקודה ישירה לציית לה. עבור סכימות מורכבות, מתן דוגמה איכותית של אובייקט מלא בהנחיה (הנחיית מספר מצומצם) יכול לשפר באופן דרמטי את הדיוק.
4. בחרו את ה-LLM הנכון לעבודה: לא כל ה-LLM נוצרו שווים בכל הנוגע לביצוע הוראות מורכבות. מודלים חדשים וגדולים יותר (לדוגמה, סדרת GPT-4, סדרת Claude 3, Llama 3) בדרך כלל טובים בהרבה ב"קריאת פונקציות" ויצירת נתונים מובנים מאשר מודלים ישנים או קטנים יותר. בדקו מודלים שונים כדי למצוא את האיזון האופטימלי בין ביצועים לעלות עבור מקרה השימוש שלכם.
5. יישמו שכבת אימות סופית: גם עם יצירה מוגבלת, כדאי שתהיה שלב אימות סופי ומוחלט. לאחר שה-LLM מייצר את הפלט, הפעילו אותו דרך מאמת באמצעות הסכימה המקורית. זה פועל כרשת ביטחון ומבטיח ציות של 100% לפני שהנתונים מועברים במורד הזרם.
6. תכננו כשלים ואדם בלולאה: אף מערכת אינה מושלמת. מה קורה כאשר מסמך המקור מעורפל או שה-LLM נכשל בחילוץ הנתונים הנדרשים? עצבו נתיבי כשל אלגנטיים. זה יכול לכלול ניסיון חוזר של הבקשה עם הנחיה שונה, חזרה למודל חזק יותר (ויקר יותר), או, חשוב מכך, סימון הפריט לבדיקה אנושית בממשק משתמש ייעודי.

העתיד מובנה: ההשפעה הרחבה יותר

המעבר לפלטים בטוחים מסוג ומובנים של AI הוא יותר מסתם שיפור טכני; זהו מאפשר אסטרטגי שיפתח את הגל הבא של טרנספורמציה המופעלת על ידי AI.

הדמוקרטיזציה של שילוב נתונים

מערכות RAG גנריות ובטוחות מסוג פועלות כ"מחבר AI אוניברסלי". אנליסטים עסקיים, לא רק מפתחים, יכולים להגדיר מבנה נתונים רצוי ולכוון את המערכת למקור חדש של מידע לא מובנה. זה מוריד באופן דרמטי את המחסום ליצירת זרימות עבודה מתוחכמות של שילוב נתונים ואוטומציה, ומעצים צוותים ברחבי הארגון לפתור את אתגרי הנתונים שלהם.

עלייתם של סוכני AI אמינים

החזון של סוכני AI אוטונומיים שיכולים ליצור אינטראקציה עם תוכנה, להזמין נסיעות או לנהל לוחות שנה תלוי לחלוטין ביכולתם להבין וליצור נתונים מובנים. כדי לקרוא ל-API, סוכן צריך ליצור מטען JSON בפורמט מושלם. כדי לקרוא ממסד נתונים, הוא צריך להבין את הסכימה. בטיחות סוג היא הבסיס שעליו ייבנו סוכני AI אמינים ואוטונומיים.

תקן חדש עבור AI ארגוני

כאשר ההייפ הראשוני סביב AI גנרטיבי מתבגר ומתמקד בערך עסקי מוחשי, הביקוש יעבור מהדגמות מרשימות למערכות בדרגת ייצור, אמינות וניתנות לביקורת. ארגונים לא יכולים לפעול על "נכון לפעמים" או "בדרך כלל בפורמט הנכון." בטיחות סוג תהפוך לדרישה שאינה ניתנת למשא ומתן עבור כל מערכת AI המשולבת בתהליכים עסקיים קריטיים למשימה, ותקבע תקן חדש למשמעות "מוכנה לארגון".

מסקנה: מעבר ליצירה להרחבה אמינה

עברנו את הנתיב האבולוציוני מהעוצמה הגולמית והיצירתית של מודלים גדולים של שפה לתגובות המבוססות על עובדות של יצירת טקסט משוחזר. אבל הצעד הסופי והמכריע ביותר במסע הזה הוא זה שמכניס משמעת, מבנה ואמינות: שילוב של בטיחות סוג.

RAG גנרי עם בטיחות סוג משנה באופן מהותי את תפקיד ה-AI בארגון. הוא מעלה מודלי LLM מלהיות רק מחוללי טקסט למנועים מדויקים ומהימנים של המרת נתונים. זה עוסק במעבר מפלט הסתברותי לנתונים דטרמיניסטיים ומובנים שניתן לשלב בצורה חלקה בלוגיקה של העולם הדיגיטלי שלנו.

עבור מפתחים, אדריכלים ומנהיגי טכנולוגיה ברחבי העולם, זו קריאה לפעולה. הגיע הזמן להסתכל מעבר לצ'אטבוטים פשוטים ומסכמי טקסט ולהתחיל לבנות את הדור הבא של יישומי AI - מערכות שהן לא רק חכמות אלא גם יציבות, צפויות ובטוחות. על ידי אימוץ התוכנית המפורטת הזו, אנו יכולים לפתוח את מלוא הפוטנציאל של AI להגדיל את היכולת האנושית ולאוטומט את זרימות העבודה המורכבות של נתונים המפעילות את הכלכלה הגלובלית שלנו.